1. Field of the Invention
The present invention generally relates to computer systems, particularly to an improved method of messaging and queuing for communication between application programs, and more specifically to a method of dynamic priority retrieval from a queue by a retrieving application.
2. Description of Related Art
Oftentimes, it is necessary for different computer programs (software applications) to communicate with one another. There are two general categories of such communicationsxe2x80x94those between different applications, and those between different component programs of a single application. In the latter case, for example, it is commonplace for a business application to be designed as a group of related programs, each of which handles a single, well-defined component of an overall task. Sometimes the programs that make up a business application run in a single environment, such as the OS/2 operating system of International Business Machines Corp. (IBMxe2x80x94assignee of the present invention). Sometimes they run in multiple, unlike environments.
Many businesses go a step further and distribute programs around their data-processing networks, rather than run them all on one processor. For example, a single application could be distributed between an IBM AIX/6000 environment on an IBM RISC System/6000 processor, and an IBM OS/400 environment on an IBM AS/400 processor. There are many advantages in this approach, most of which are related to making better use of resources. However, when a single application is distributed, whether to unlike environments on a single processor or to different nodes of a network, there must be a way of getting the parts of the application to communicate with each other. This communication can be challenging enough when the components of the network are from a single vendor (i.e., when there are no variations in the operating systems being used, and when there""s a single communication protocol). The problem is even more challenging when the network components are from a variety of vendors, and multiple communication a protocols are being used.
The interoperability challengexe2x80x94the challenge of getting programs to communicate across unlike environmentsxe2x80x94faces many information system managers today. Until recently, connecting disparate systems like this has been a difficult technical task, and getting different technologies to work together across an enterprise can be a nightmare. Ad hoc solutions to link two systems are complex to program, and prove inflexible if the systems need to change with the business. Often the solution adopted is human interventionxe2x80x94people are used to bridge the gap via phone, fax or e-mail. Inevitably, mistakes occur when high volumes of data are re-keyed, pieces of paper are lost or e-mail mysteriously goes astray with no audit trail.
A fundamental business integration approach to dealing with the foregoing problem is known as message queuing. Message queuing provides reliable transfer of information between computer applications, regardless of the type of computer or network. It acts in a way analogous to an administrative assistant managing the in-trays and out-trays on office desks. The assistant can place xe2x80x9chigh priorityxe2x80x9d items on top of the piles in these trays, so that they are dealt with first and, if necessary, can check on the safe delivery of important items. Some commercial queuing packages, such as IBM""s MQSeries, offer a high-level application program interface (API) which shields programs from the complexities of different operating systems and underlying networks.
A message is mainly a string of bits and bytes (data representing items such as account numbers, account balances, booking requests, names and addresses, images of documents, etc.) that one program wants to send to another. This type data is often called application data. Of course, a message needs to include other information, such as its destination and possibly a return address. This type of data is called the message descriptor. A program sending a message defines the application data and supplies it. Such data can include character strings, bit strings, binary integers, packed-decimal integers, floating-point numbers, etc.
There are generally four types of messages: a xe2x80x9crequestxe2x80x9d message is used by one program to ask another program for something (usually data); a xe2x80x9creplyxe2x80x9d message is used in response to a request message; a xe2x80x9cone-wayxe2x80x9d message requires no reply, though it can carry data; and a xe2x80x9creportxe2x80x9d message is used when something unexpected occurs. For example, if the data in a reply message is not usable, the receiving program might issue a report message. Messages are labeled in this way so that the target program can know. what""s expected of it, without having to examine the message in detail.
A message queue is an area of storage set aside (by a xe2x80x9cqueue managerxe2x80x9d) to hold messages on their way from one program to another. FIG. 1 illustrates optional two-way communication between programs using queues. Program A communicates with program B via Queue 1. If Program B needs to communicate with Program A (whether to reply to a request from Program A or for some unrelated reason), it puts a message on Queue 2. Either program can be busy or unavailable at the time a message is put in its queue. Queues can also be set up in a one-to-many relationship, or a many-to-one relationship. A collection of different types of queues can be used to provide complete communications between a particular set of programs.
By default, a message queue works like a physical queue: first in is first out (FIFO). When using a queuing package, however, it is sometimes desirable to pull items out of the queue in priority. Unfortunately, most message queuing packages only allow the priority of a message to set at the moment a message is placed on a queue. It is then impossible to change the priority of a message, and thus the order the messages will be retrieved.
Some queuing packages do allow the setting of a xe2x80x9ckeyxe2x80x9d on a message. A receiving process (program) specifies a particular key on its call to get a message from a queue, and only messages with that same key will be returned. This approach may incidentally allow prioritization of messages, but only if the receiving process assigns a high priority to a particular key. If there are no messages with that key, it then looks for its second most important key, etc. However, most queuing software requires that the key on the message and the key in the get call match exactly. This approach eliminates being able to search for categories of keys. Also, the number of keys that a single message can have is very limited, usually only one or two, restricting the manner in which properties of a message can be stored in the keys of a message. It would, therefore, be desirable to devise a method of pulling messages out of a queue with dynamic priority, whereby the process pulling the messages out could be able to describe which types of messages are more important, and the queuing system return those messages in that priority.
It is therefore one object of the present invention to provide a system allowing improved communications between computer programs or program components.
It is another object of the present invention to provide such a system that uses messages and queuing to enable inter-program communications, particularly between programs residing in different environments.
It is yet another object of the present invention to provide a messaging and queuing system that facilitates dynamic prioritization and handling of messages.
The foregoing objects are achieved in a method of queuing messages for communications between computer programs, generally comprising the steps of placing a plurality of messages in a main queue, placing one or more property messages in one or more property queues associated with the main queue and, for each property message, specifying at least one property of a respective message in the main queue and a unique identifier for the respective message. A property name may be specified for a message, or a property value, or some combination of property names and values. An application program interface (API) makes the main queue and the one or more property queues appear as a single priority queue. In the illustrative embodiment, each property message is a zero-byte message having first and second keys, the at least one property is specified as the first key, and the unique identifier is specified as the second key. The number of properties for a given message can be less than the number of property queues.
A message is retrieved from the main queue according to a predefined priority list which includes the at least one property, which can again be a property name, a property value, or some combination of property names and values. The priority list can be dynamically modified. In the implementation wherein the placing steps are performed by a first computer connected to a network, and the retrieving step is performed by a second computer connected to the network, the plurality of messages are transmitted across the network.
The above as well as additional objectives, features, and advantages of the present invention will become apparent in the following detailed written description.